Method and system for controlling traffic load between media gateway controllers and proxies

ABSTRACT

The invention refers a method of regulating the traffic that may be used between a SIP User Agent (SIP-UA) and a SIP Proxy in high traffic load situations, like in a telephony-SIP inter-working senario where the MGC in the inter-working gateway is acting as a SIP-UA. Thus, a method to fit the traffic between these two nodes into some margins which suit both node capabilities. The method comprises two procedures. The first procedure proposes a mechanism for any of both nodes, so called requesting node, to indicate the opposite node to act upon its traffic towards the requesting node. The reference for such decision is the current traffic being received at the requesting node at that very same moment. Any further traffic regulation indication will be related to the corresponding traffic level at the moment every new indication is issued, not necessarily being related to the traffic level being handled as previous indications were sent. This first procedure is the basic flow control protection between both nodes. The second procedure adds some fine controls to the first procedure. It allows both nodes to explicitly exchange capability values that will be used from that point on as a reference for any indication to act upon the traffic among both nodes. So, this second procedure provides a more permanent reference for any successive traffic regulation indication. The first procedure allows both nodes to control the traffic between them without knowing anything about each other&#39;s capabilities.

The present invention relates generally to traffic load limitationsbetween the Telephony domain and the Internet domain, wherein the borderbetween said Telephony and Internet domains is represented by aninter-working network entity. More specifically, the invention relatesto the traffic flow control to be implemented in this inter-workingnetwork entity.

BACKGROUND

There is currently a great interest world wide in providinginter-working between Telephony and Internet Protocol (IP) basednetworks in order to extend their respective services and advantagesinto the other network. One of the main reasons behind this interestresides on the increased flexibility and reduced operating costcharacteristics of IP-based networks as transporting circuit switchednetwork related signalling information between signalling points. Suchinter-working between Telephony and IP-based networks is commonlyrepresented by an inter-working node acting as the border between bothcorresponding domains, the Telephony domain and the IP domain. Thisinter-working node is in charge of attending all the incoming requestsfrom the IP domain as well as of sending all the traffic coming from thetelephony domain to the IP domain.

One of the preferred protocols in the IP domain for call/session controlis the Session Initiation Protocol (SIP), which is now underspecification by the SIP Working Group of the Internet Engineering TaskForces (SIP IETF WG), within the Transport Area. In fact, several SIPentities, the so called Call Status Control Function (CSCF), have beendefined in the third Generation Partnership Project (3GPP) which allowthe Circuit Switched and the IP multimedia domains be interconnected.

In this respect, it is noticeable the effort in order to define protocolmapping mechanisms to make this inter-working possible between IP andCircuit Switched networks. For example, the SIPPING Working Group withinthe Transport Area of the IETF defines the SIP-T framework to facilitatethe interconnection of the Public Switched Telephone Network (PSTN) withthe IP network. On the other hand, the Integrated Services DigitalNetwork (ISDN) is nowadays a world wide spread network shared by bothfixed and mobile networks wherein the ISDN User Part (ISUP) of aSignalling System #7 (SS7) is the signalling protocol that said ISDNmakes use of. In this respect, the ISUP to SIP Mapping is anotherinitiative from the SIP IETF WG, describing a way to perform the mappingbetween said two signalling protocols.

The current architectural proposals for this inter-working node, borderbetween the Telephony and the IP domains, go towards some gatewaydecomposition approach, as basically resulting from studies carried outby the International Telecommunications Union (ITU), the EuropeanTelecommunication Standard Institute (ETSI), the Multi-Switching ServiceForum (MSF), and the above referred IETF standardization bodies.

The current inter-working node comprises a Media Gateway (MGW)responsible for establishing call connections over a bearer network, anda Media Gateway Controller (MGC) implementing call control relatedprocedures connected to the Media Gateway. Both nodes communicate toeach other by making use of a control protocol, which is described inthe ITU-T Recommendation H.248, and is also followed up by the MEGACOWorking Group within the Transport Area in the IETF.

From a SIP domain viewpoint, the inter-working node acts as a SIP UserAgent (hereinafter SIP-UA) that is connected to at least one of aplurality of SIP proxies located in the IP domain. Said inter-workingbetween SIP-UA and SIP-Proxy is then regarded as the main bottleneckbetween both Telephony and IP Domains, namely between both Telephony andIP networks where SIP is used. Moreover, this main drawback extendsbeyond the inter-working between Telephony and IP networks, This maindrawback is a rather negative influence on any general scenariocomprising SIP-UA and SIP-Proxy connections. In such a scenario, thereis still a lack of reliable flow control mechanisms to avoid theinter-working nodes becoming temporarily unavailable, or even beingcompletely down, just because they are not able to handle as muchtraffic as they might be receiving at a certain time.

RELATED ART

There are multiple instances of the currently accepted separationbetween call control and bearer control that the aforementioned gatewaydecomposition in a MGC and a MGW is aimed to. For example and justincorporated by reference, the international patent applicationWO-01/49045 provides for a method of transporting Call control relatedsignalling between a first network employing SS7 signalling and a secondnetwork in which Call control functionality is handled in a MGC andBearer control in a MGW. The method includes the distribution of callcontrol signalling to the MGC through a MGW, said MGW controlled by theMGC using the MEGACO protocol. This separation of call controlsignalling and bearer control signalling introduces the rational for aso called Bearer Independent Call Control (BICC) protocol as well as fora so called Transport Independent Call Control (TICC). Further, thisinternational application points out that the Call control signallingcould be sent for example over an IP network or over an SS7 network.Furthermore, the SIP protocol is noticed as an alternative transportindependent control protocol to TICC. However, this application does notexplain how the MGC maps incoming ISUP Call control signalling to SIPrelated Call control signalling, or how the MGC behaves as a SIP-UAtowards the SIP domain, or, even less, how traffic flow control can becarried out between SIP-UA and SIP-Proxy.

On the other hand, the United States Patent Application 20010023453describes a method and an arrangement in a data packet communicationsystem for providing users the possibility to control the availablebandwidth of application data flows in and out of the terminal inaccordance with the user's preferences. This invention provides the userwith a possibility to speed up applications that are found to be moreimportant by restricting application flows of applications that arefound less important. Incoming application data flows are controlled bymanipulating window sizes that are reported to the respective senders ofthe incoming application flows. Outgoing data flows are controlled bysupervising the sending times of data packets on the different outgoingapplication flows. Control decisions are based on information about theuser's preferences, which information is stored in a memory in theterminal. The teaching of this patent application is mainly addressed tocontrol individual data flows in accordance with user's preferences.However, there is no direct applicability from the rational behind thisapplication to implement a network traffic flow control between a SIP-UAand a SIP-Proxy, said flow control carried out by cooperating entitiesto the one suffering unavailability for handling traffic. Moreover, thisapplication is rather focusing on prioritising incoming and outgoingdata flows based on user's preferences than on implementing flow controlmechanisms between SIP-UA and SIP-Proxy for them to keep on workingwithin safe traffic load margins and serving many users origin anddestination of these traffic flows.

The international patent application WO 01/28257 introduces interestingaspects to consider as analysing the known prior art. This applicationteaches a method of prioritising actions at a gateway to a bearernetwork, said gateway comprising a MGW responsible for establishing callconnections over the bearer network, and a MGC coupled to the MGW. SaidMGC determines the priority of signalling messages received, andconverts them into so called Media Gateway Control Protocol (MGCP)messages including a parameter to indicate the priority of theassociated signalling message. The MGCP message is then transferred tothe MGW, which acts upon the message in accordance with the indicatedpriority. This message priority is useful to speed up the handling andtreatment of calls with higher priority, whereas messages with lowerpriority can wait without suffering unacceptable delays. There is agreat advantage on this teaching since the support for message priorityis an advantageous aspect as implementing a realistic flow control basedon co-operation from adjacent nodes. However, there is no explanation inthis international application on how to carry out a sort of flowcontrol mechanism shared by the co-operating entities involved.

That is, focusing on the aforementioned inter-working betweenconventional Telephony and Internet networks, respectively representedby the Telephony and SIP domains, the Media Gateway Controller is withinthe interconnecting node the entity that implements the call controlprocedures in the telephony domain. Additionally, this entity is actingas a SIP User Agent accordingly with the specifications of the IETFRequest For Comments (RFC) 2543“SIP: Session Initiation Protocol”.However, there is no known mechanism yet to carry out a traffic flowcontrol at this MGC acting as a SIP-UA towards the SIP domain, saidmechanism being appropriately co-ordinated with the existing one towardsthe Telephony domain.

The inter-domain traffic is typically negotiated at call control levelbetween the MGC acting as a SIP-UA and the SIP-Proxy that it isconnected to. These two nodes, the SIP-UA and SIP-Proxy, constantlyreceive requests from each other asking for new calls to be established,which will be directly controlled by them. In case of high traffic fromthe opposite node, for example from the SIP-UA to the SIP-Proxy, theremay be a lack of processing capacity in the receiving node, namely inthe SIP-Proxy.

Currently, both nodes can somehow control this SIP-related traffic flowjust using any flow control mechanism that the transport level mightprovide, depending on the underlying protocol layers and technologiesinvolved. This dependence makes insufficient any flow control mechanismto solve any overload situation between a SIP-UA and a SIP-Proxy basedonly on facilities offered by the transport layer. For instance, theUser Datagram Protocol (UDP) does not include any sort of flow controlmechanism. Moreover, in chapter 23.5.4 “503: Service Unavailable” of theaforementioned RFC 2543, some actions are suggested at SIP level thatmight be taken at a certain reference node in order to inform otheradjacent node that said reference node is undergoing some overloadsituation. That is, current trends address to not just trusting any flowcontrol mechanism that the transport level may provide with but ratherto other mechanisms at the SIP level. Nevertheless, the way out outlinedin said chapter in RFC 2543 just suggests a black-or-white solution,thus the traffic is re-routed to other server until the unavailable noderecovers and goes back to a normal situation.

In this respect, it is a main object of the present invention to providea solution for allowing a certain SIP node under reference to informother adjacent SIP nodes about its current availability measurements.Said adjacent SIP nodes may act with this information to carry out flowcontrol mechanisms by grading and controlling their respective trafficload towards the SIP node under reference. These traffic flow controlmechanisms, proposed by the present invention, define an inter-workingframework for a SIP-UA and a SIP-Proxy to keep on working under hightraffic conditions. Specifically, when the SIP-UA resides in a MediaGateway Controller (MGC), said SIP-UA might likely be connected to asingle SIP-Proxy being said SIP-Proxy generally known as an OutboundSIP-Proxy. Such a couple SIP-UA and SIP-Proxy can be regarded as thebasic scenario to apply traffic flow control mechanisms in accordancewith the present invention.

Further, it is another object of the present invention to provide thesetraffic flow control mechanisms in broader scenarios than theaforementioned couple SIP-UA and SIP-Proxy. Said broader scenarioscomprising a plurality of SIP nodes which in particular may be acting asSIP-UA, SIP-Proxy or any combination thereof.

SUMMARY OF THE INVENTION

A first embodiment of the present invention accomplish said objects byproviding a method to carry out flow control mechanisms between networknodes that are responsible for signalling multimedia sessions over datanetworks allowing said nodes keeping on working under high trafficconditions.

In a first aspect, the method allows the implementation of a first flowcontrol mechanism called Capacity Adjustment Indication (CAI) mechanismbetween, at least, two connected nodes for at least one direction of thetraffic flow. The method includes a negotiation between said nodes,initiated at any one of them, to agree on the availability of a CAImechanism in both nodes for controlling the traffic flow between them inat least one traffic flow direction. A requester node that, for example,suffers a capacity limitation initiates the negotiation. Said requesternode indicating to a requested node at least one traffic flow directionfor which a CAI mechanism is supported in the requester node. Thenegotiation ends with the confirmation that said mechanism is alsosupported in the requested node. Then, the existing CAI mechanism(s)is/are used for accommodating the traffic load between said nodes to thecapacity of the traffic receiver node in the direction(s) of the trafficflow for which both nodes support the CAI mechanism(s). For achievingsaid accommodation, the capacity limitations of the traffic receivernode are determined, then the traffic receiver node sends capacityadjustment indications to the traffic sender node which store saidindications and acts upon the traffic flow in accordance with them. Thecapacity adjustment indications sent from the traffic receiver node tothe traffic sender node include information about the maximum incomingtraffic load that said traffic receiver node is able to deal with fromsaid traffic sender node and about the units in which traffic ismeasured.

In a second aspect, the method allows the implementation of a secondflow control mechanism called Capacity Reference Exchange (CRE)mechanism between, at least, two connected nodes for, at least onedirection of the traffic flow. The method includes a negotiation betweensaid nodes, initiated at any one of them, to agree on the availabilityof a CRE mechanism in both nodes for controlling the traffic flowbetween them in at least one traffic flow direction. The negotiation isinitiated by a requester node indicating to a requested node at leastone traffic flow direction for which a CRE mechanism is supported in therequester node and ends with the confirmation that said mechanism isalso supported in the requested node. Then, the existing CREmechanism(s) is/are used for establishing a maximum reference limit forthe traffic flow between said nodes in the direction(s) of the trafficflow for which both nodes support the CRE mechanisms. The implementationof the CRE mechanism includes a first step in which the maximum trafficload supported in both nodes for both traffic directions is determined.Then, a second step in which both nodes exchange information regardingtheir capacity references. Finally, the nodes agree on a capacityreference supported by both of them.

The CAI mechanism is the “core” flow control mechanism of the presentinvention. The CRE mechanism adds some “fine” controls to the CAImechanism, but it is not mandatory for the CAI mechanism to work.

The flow control mechanisms, “core” and “fine”, carried out according tothe method applies, in broader scenarios, to SIP nodes, acting inparticular as SIP-UA or SIP-Proxy. However the basic scenario for themethod is a SIP-UA node residing in a Media Gateway Controller (MGC)connected to a single SIP-Proxy node, generally known as an OutboundSIP-Proxy.

A second embodiment of the present invention provides atelecommunications system comprising a first Media Domain whereinmultimedia sessions are signalled by a protocol operating according to aSession Initiation Protocol, a second Media Domain wherein multimediasessions are signalled by a protocol operating according to a secondstandard. Said telecommunications system also comprises Media Gatewaysin charge of receiving and sending media between said first and secondMedia Domains, and Media Gateway Controllers for receiving and sendingsignalling related to multimedia sessions between said first and secondMedia Domains. The aforementioned telecommunications system in which twoconnected nodes carry out a negotiation to agree on whether capacityadjustment indication (CAI) mechanisms exist in both nodes forcontrolling the traffic flow between them in at least one of bothdirections, said negotiations being initiated at any one of said nodes.The negotiation and implementation of the existing CAI mechanisms takesplace in similar manner as the one described above.

In said telecommunications system, two connected nodes may also carryout a second negotiation to agree on whether capacity reference exchange(CRE) mechanisms exist in both nodes for establishing maximum referencelimits for the traffic flow in at least one of both directions andimplement the existing CRE mechanisms.

BRIEF DESCRIPTION OF DRAWINGS

The features, objects and advantages of the invention will becomeapparent by reading this description in conjunction with theaccompanying drawings, in which:

FIG. 1 basically illustrates system architectures comprising a typicalTelephony domain inter-working with a SIP domain via a coupled MediaGateway and Media Gateway Controller.

FIG. 2 a, 2 b, 2 c and 2 d present particular sequence diagrams ofpossible negotiations for supporting basic flow control mechanisms in atleast one of both proposed directions between two entities in a SIPdomain.

FIG. 3 a, 3 b, 3 c and 3 d present particular sequence diagrams ofpossible negotiations for supporting basic flow control mechanisms injust one direction proposed between two entities in a SIP domain.

FIG. 4 a, 4 b, 4 c and 4 d present particular sequence diagrams ofpossible negotiations for supporting additional mechanisms forestablishing maximum reference traffic limits in at least one of bothproposed directions between two entities in a SIP domain.

FIG. 5 a, 5 b, 5 c and 5 d present particular sequence diagrams ofpossible negotiations for supporting additional mechanisms forestablishing maximum reference traffic limits in just one directionproposed between two entities in a SIP domain.

FIGS. 6 a and 6 b show instances of negotiation and operation of thebasic mechanism for flow control between two entities in a SIP domain,said mechanisms in FIG. 6 a and FIG. 6 b respectively acting in a “stepby step” performance and in a “all of a sudden” performance.

FIGS. 7 a, 7 b and 7 c show examples of negotiation and operation of theadditional mechanism for establishing maximum reference traffic limitsbetween two entities in a SIP domain. In particular FIG. 7 b shows hownegotiation of basic and additional mechanisms may be carried outsimultaneously.

FIG. 8 illustrates an example of negotiation and operation of both basicmechanism for flow control and additional mechanism for establishingmaximum reference traffic limits carried out between two entities in aSIP domain.

FIG. 9 a, 9 b, 9 c and 9 d present exemplary sequence diagrams ofpossible deactivation of basic, or additional, or both mechanismscarried out on a per basic mechanism, or per additional mechanism, orper combinations thereof between two entities in a SIP domain.

FIG. 10 illustrates a generic SIP domain wherein a plurality of firstSIP nodes inter-work with a plurality of second SIP nodes, eachparticular couple of a first and a second node able to negotiate andoperate the basic mechanism for flow control and the additionalmechanism for establishing maximum reference traffic limits.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following describes currently preferred embodiments of methods andapparatus to provide traffic flow control mechanisms between a pluralityof SIP nodes which in particular may be acting as SIP-UA, SIP-Proxy orany combination thereof. For explanatory purposes, and for the sake ofclarity, the following description usually refers to mechanisms betweena SIP-UA and a SIP-Proxy, however, these preferred embodiments are alsoapplicable to the aforementioned plurality of SIP nodes, and thusspecifically pointed out when appropriate, likely with additional andparticular details.

Generally speaking, some traffic information is exchanged between aSIP-UA and a SIP-Proxy wanting to implement explicit flow controlmechanisms between them.

More specifically, these mechanisms include two different proceduresinvolving a new SIP header each, and both procedures controlled throughthe use of new option-tags in the existing so called ‘Supported’ SIPheader.

A first procedure, the so-called ‘Capacity Adjustment Indication’,represents primary mechanisms of this flow control, and core of thisproposal. These primary mechanisms allow the SIP-UA and the SIP-Proxy torequest each other the accommodation of the traffic load to the currentcapacity situation. For example, one might request the other to firstreduce the traffic between them, in order to cope with some traffichandling limitations, and then to increase that traffic rate again whenthe limiting cause is over. In accordance with a first aspect ofpreferred embodiments, this first procedure is associated to two newoption-tags in the existing ‘Supported’ SIP header. These newoption-tags as well as the format for the corresponding first new SIPheader are further described in detail with reference to explanatory usecases and examples.

A second procedure, the so-called ‘Capacity References Exchange’,represents a secondary mechanism of this flow control that adds somefine controls to the previous ones, though it is not mandatory for theprimary mechanisms to work. In accordance with a second aspect ofpreferred embodiments, this second procedure is associated to anothertwo new option-tags in the existing ‘Supported’ SIP header. These othertwo new option-tags as well as the format for the corresponding secondnew SIP header are also further described in detail with reference toexplanatory use cases and examples.

The first procedure, the so-called Capacity Adjustment Indication(hereinafter referred to as CAI), is based on handshake relatedfeatures. These handshake features allow the SIP nodes to negotiate, andagree on, to what extent they both are able to support such a firstprocedure. For instance, an object of negotiation between SIP nodes suchas a SIP-UA and a SIP-Proxy, namely a handshake feature, is whether amechanism is available to control the traffic flow coming out from theSIP-UA towards the SIP-Proxy. Another handshake feature within thisfirst procedure is whether a mechanism is available to control thetraffic flow coming out from the SIP-Proxy towards the SIP-UA. Indeed,if one SIP node such as a SIP-UA or a SIP-Proxy supports any of thesetwo features, the other adjacent node must also support the same featurein order to effectively carry out the traffic flow control in theappropriate direction.

In accordance with a said first aspect of the currently preferredembodiments, two new flow control related option-tags may be used ashandshake features within these primary mechanisms in order to limit thescope of the applicable flow control according to what is supported byboth SIP nodes:

(i) a first option-tag, the so-called ‘fcua2proxy’, meaning that anagreement on this new feature indicates that a mechanism is available tocontrol the traffic flow coming out from the SIP-UA towards theSIP-Proxy; and

(ii) a second option-tag, the so-called ‘fcproxy2ua’, meaning that anagreement on this new feature indicates that a mechanism is available tocontrol the traffic flow coming out from the SIP-Proxy towards theSIP-UA.

For example, when the SIP-UA tells the SIP-Proxy that it supports thenew feature ‘fcua2proxy’, it means that the SIP-UA is ready to accept acapacity adjustment request from the SIP-Proxy to act upon the trafficflow towards said SIP-Proxy. On the other hand, when the SIP-Proxy tellsthe SIP-UA that it supports such new feature, it means that theSIP-Proxy expects the SIP-UA to accept capacity adjustment requests toact upon the traffic flow towards the SIP-Proxy. Similarly, when theSIP-UA tells the SIP-Proxy that it supports the new feature‘fcproxy2ua’, it means that the SIP-UA expects the SIP-Proxy to acceptcapacity adjustment requests to act upon the traffic flow towards theSIP-UA. On the other hand, when the SIP-Proxy tells the SIP-UA that itsupports this new feature, it means that the SIP-Proxy is ready toaccept a capacity adjustment request from the SIP-UA to act upon thetraffic flow towards the SIP-UA. Nevertheless, if for example the SIP-UAsupports ‘fcua2proxy’ but the SIP-Proxy does not support it, no flowcontrol mechanism will be enabled to control the traffic flow from theSIP-UA towards the SIP-Proxy.

Alternative embodiments may be suggested to negotiate the aforementionedhandshake features. Generally speaking, a handshake implies messages onthe onward and backward directions. In accordance with a currentlypreferred embodiment, the handshake can be performed during the SIPRegistration mechanism. That is, as the SIP-UA registers at theSIP-Proxy, the existing ‘Supported’ header is included in the SIPREGISTER message from the SIP-UA showing whether the SIP-UA supports anyof these two new features. Then, the SIP-Proxy confirms back, forinstance with a ‘200 OK’ successful response, whether its ownconfiguration for flow control supports what has been requested from theSIP-UA. If not, the existing ‘Unsupported’ header may be used to showwhich features are not supported.

Another embodiment not substantially different from the previous one maybe the adaptation of the OPTIONS method as described in theaforementioned IETF RFC 2543. Said RFC states that the response to aprevious OPTIONS method may contain a message body indicating thecapabilities of the end-system rather than properties of any existingcall, and these new handshake features are actually end-system or noderelated capabilities. Thus, this alternative embodiment proposes thatthe SIP node issuing the OPTIONS includes the existing ‘Supported’header to show which of these two new handshake features said SIP nodeis supporting. The adjacent SIP node confirms back in the response tothe OPTIONS method whether its own flow control configuration supportswhat has been requested from the sending node. If not, the existing‘Unsupported’ header will be used to show which features are notsupported. The OPTIONS alternative would work in a similar manner as theadapted SIP Registration procedure with the additional advantage thatthe SIP-Proxy would be able to start the feature negotiation in thiscase too. However and provided that this alternative embodiment ispreferred, the normal SIP Registration procedure should have beenpreviously performed.

These or other alternative embodiments, or adaptations thereof, can beused for the same or similar purposes without modifying the substantialscope of the present invention as anyone skilled in the art mayappreciate. For the sake of clarity, all the examples, use cases, andadditional embodiments for other aspects of the present invention arehereinafter described only with regard to the adapted SIP Registrationmechanisms.

In FIG. -2 a- the SIP-UA can handle flow control in both directions,that is, the SIP-UA supports both the ‘fcua2proxy’ and ‘fcproxy2ua’ newfeatures, which are thus included in the ‘Supported’ header in the SIPREGISTER message. Since the SIP-Proxy supports both of them as well, theSIP-Proxy answers the successful result ‘200 OK’ with no ‘Unsupported’header. From now on, both features are eventually enabled between bothnodes, and both nodes may request each other to adjust the trafficbetween them.

In FIG. -2 b- the SIP-UA also supports both new features, ‘fcua2proxy’and ‘fcproxy2ua’, which are thus included in the ‘Supported’ header inthe SIP REGISTER message. However, the SIP-Proxy does not support anyflow control for traffic from the SIP-Proxy to the SIP-UA and,consequently, the SIP-Proxy answers the successful result ‘200 OK’ withan ‘Unsupported’ header including the unsupported feature ‘fcproxy2ua’.From now on, just the ‘fcua2proxy’ is enabled and ‘fcproxy2ua’ isfinally disabled. That is, just the SIP-Proxy may request the SIP-UA toact upon the traffic towards the SIP-Proxy.

In FIG. -2 c- the SIP-UA also supports both new features, ‘fcua2proxy’and ‘fcproxy2ua’, which are thus included in the ‘Supported’ header inthe SIP REGISTER message. However, the SIP-Proxy does not support, orrather does not require, any flow control for incoming traffic from theSIP-UA and, consequently, the SIP-Proxy answers the successful result‘200 OK’ with an ‘Unsupported’ header including the unsupported feature‘fcua2proxy’. From now on, just the ‘fcproxy2ua’ is enabled whereas‘fcua2proxy’ is eventually disabled. That is, just the SIP-UA mayrequest the SIP-Proxy to act upon the traffic towards said SIP-UA.

In FIG. -2 d- the SIP-UA also supports both new features, ‘fcua2proxy’and ‘fcproxy2ua’, which are thus included in the ‘Supported’ header inthe SIP REGISTER message. However, the SIP-Proxy does not require ordoes not support any flow control for incoming or outgoing traffic fromor to the SIP-UA and, consequently, the SIP-Proxy answers the successfulresponse ‘200 OK’ with an ‘Unsupported’ header including bothunsupported features ‘fcua2proxy’ and ‘fcproxy2ua’. That is, both‘fcproxy2ua’ and ‘fcua2proxy’ are eventually disabled, and none of thenodes may request the other to act upon the traffic between them.

The SIP-UA in these four previous use-cases was always able to supportflow control mechanisms in both directions. That is, said SIP-UA alwayssupported both new handshake features ‘fcua2proxy’ and ‘fcproxy2ua’.There might be, however, situations in which the initiator of handshakein a preferred embodiment making use of the adapted SIP Registrationprocedure, namely the SIP-UA, only supports flow control in onedirection. In this case, the unsupported handshake feature in the SIP-UAdoes not even deserve being negotiated.

For instance, in FIG. -3 a- the SIP-UA only supports the ‘fcproxy2ua’new feature, which is thus included in the ‘Supported’ header in the SIPREGISTER message. Since the SIP-Proxy also supports this feature, theSIP-Proxy answers the successful result ‘200 OK’ with no ‘Unsupported’header. From now on, just the ‘fcproxy2ua’ is enabled whereas‘fcua2proxy’ is eventually disabled. That is, just the SIP-UA mayrequest the SIP-Proxy to act upon the traffic towards said SIP-UA.

In FIG. -3 b-, the SIP-UA only supports the ‘fcproxy2ua’ new feature,which is thus included in the ‘Supported’ header in the SIP REGISTERmessage. However, the SIP-Proxy does not support any flow control fortraffic from the SIP-Proxy to the SIP-UA and, consequently, theSIP-Proxy answers the successful result ‘200 OK’ with an ‘Unsupported’header including the unsupported feature ‘fcproxy2ua’. That is, from nowon both ‘fcproxy2ua’ and ‘fcua2proxy’ are eventually disabled, and noneof the nodes may request the other to act upon the traffic between them.

Also for instance, in FIG. -3 c- the SIP-UA only supports the‘fcua2proxy’ new feature, which is thus included in the ‘Supported’header in the SIP REGISTER message. Since the SIP-Proxy also supportsthis feature, the SIP-Proxy answers the successful result ‘200 OK’ withno ‘Unsupported’ header. From now on, just the ‘fcua2proxy’ is enabledwhereas ‘fcproxy2ua’ is eventually disabled. That is, just the SIP-Proxymay request the SIP-UA to act upon the traffic towards said SIP-Proxy.

In FIG. -3 d-, the SIP-UA only supports the ‘fcua2proxy’ new feature,which is thus included in the ‘Supported’ header in the SIP REGISTERmessage. However, the SIP-Proxy does not support, or rather does notrequire, any flow control for incoming traffic from the SIP-UA and,consequently, the SIP-Proxy answers the successful result ‘200 OK’ withan ‘Unsupported’ header including the unsupported feature ‘fcua2proxy’.That is, from now on both ‘fcproxy2ua’ and ‘fcua2proxy’ are eventuallydisabled, and none of the nodes may request the other to act upon thetraffic between them.

After this initial handshake has been carried out, and according to whathas been agreed on, any SIP node might be able to send capacityadjustment indications to the adjacent node in order to alter thetraffic rate between them. To this end, the scenario resulting from aninitial handshake carried out in accordance with FIG. -3 c- is taken asa reference case following this in order to describe the capacityadjustment procedure. More precisely, the ‘fcua2proxy’ feature isenabled; that is, flow control from SIP-UA to SIP-Proxy is supported.Similar teaching may be inferred from the reverse direction as anyoneskilled in the art may appreciate.

A successful negotiation resulting from the initial handshake scenarioin FIG. -3 c- means that the SIP-Proxy will keep an eye on the trafficcoming from the SIP-UA. If anything happened for the SIP-Proxy to acceptless traffic from the SIP-UA, a request would be sent to the SIP-UA toadjust the traffic flow to the new conditions. The SIP-UA, having agreedon this flow control during the initial handshake procedure, will beready to receive that capacity adjustment request at any time.

Generally speaking, the node towards which the traffic is beingflow-controlled, namely the requesting node, is given the logic todetect capacity limit situations, maintenance activities for example, oris able to detect that the node has just reached its maximum capacitylimit. If this happens, the requesting node, the SIP-Proxy in thisexample, initiates a Capacity Adjustment Initiation request towards theadjacent co-operating node, the SIP-UA in this example, requiring lesstraffic to be accepted from said adjacent node as a possible action tocompensate the lack of capacity. The SIP-UA, at reception of a CapacityAdjustment Initiation request from the SIP-Proxy, understands that ifthe traffic rate towards the SIP-Proxy is not reduced, some trafficrequests would probably be rejected at the SIP-Proxy without even beinganalysed.

Said Capacity Adjustment Initiation request may be implemented byfunctional equivalent means as easily appreciated. In accordance withcurrently preferred embodiments, a new SIP header is proposed in orderto implement this capacity adjustment mechanism, focussing on providinga mechanism to alternatively decrease or increase the traffic ratebetween both nodes appropriately to the current capacity limits. To thisend, said new SIP header may comprise a percentage representing themaximum incoming traffic load that the requesting node is able to dealwith from the adjacent node. The new SIP header may also comprise otherindications such as the units in which traffic is measured. An exemplaryformat for said SIP header follows this:

-   Capacity-adjust: “Capacity adjust” “:”    -   traffic-percentage traffic-ref-   traffic-percentage: 1*3DIGIT    -   Range from ‘000’ to ‘100’.    -   Percentage of acceptable    -   ‘current-traffic’.-   traffic-ref: 1*DIGIT traffic-units    -   Traffic figure which the    -   ‘traffic-percentage’ is        -   referred to.-   traffic-units: “mess/s” | “trans/s” | “call/s”    -   mess/s (messages per second),    -   where ‘messages’ are all SIP    -   methods (i.e. INVITE, ACK,    -   OPTIONS, BYE, CANCEL, REGISTER    -   and INFO) and all provisional    -   and final responses;    -   trans/s (transactions per        -   second), including both SIP and        -   regular transactions;    -   call/s (calls per second),    -   referred to the whole period    -   since the initial INVITE till    -   the completion of the call.-   DIGIT:    -   as described in ‘SDP: Session    -   Description Protocol’.

The requesting node, the SIP-Proxy in this example, is able to measurethe traffic handled from the adjacent node, the SIP-UA in this example,at the time the overload situation arises. Those traffic figures areused as a reference, namely the ‘traffic-ref’ in ‘Capacity-adjust’above, for the required percentage to be indicated in the field‘traffic-percentage’ included in ‘Capacity-adjust’. This‘Capacity-adjust’ new header may be sent from the SIP-UA to theSIP-Proxy, and vice versa, in all methods (i.e. INVITE, ACK, OPTIONS,BYE, CANCEL, REGISTER, INFO) and in all provisional and final responses.No response is required from the opposite node.

Still a further and more precise use-case may be presented withreference to the scenario resulting from the handshake procedure shownin FIG. -6 a- and FIG. -6 b-. After this initial handshake, the SIP-UAstarts sending traffic towards the SIP-Proxy with no more initiallimitation than its own internal limits to generate traffic. The sameconsiderations are applicable for the SIP-Proxy. At a certain time, theSIP-Proxy detects a faulty situation. Because of that fault, theSIP-Proxy decides that part of the traffic being received from theSIP-UA can not be accepted for a while, thus being rejected. TheSIP-Proxy analyses how much traffic is being handled from the SIP-UA atthat very same time, in this example ‘50 calls/s’, and decides how muchtraffic from the SIP-UA can be allowed from that time on. For example,the acceptable traffic might be 60% of ‘50 calls/s’. Then, the SIP-Proxyinforms the SIP-UA about it by including the new SIP header‘Capacity-adjust’ in the first message towards the SIP-UA. Provided thatthe SIP-Proxy did not inform the SIP-UA about its traffic handlinglimitations, for instance if this solution was not implemented, anytraffic over the new capacity limit would be rejected at the SIP-Proxy.The flow control mechanisms in accordance with the invention allow theSIP-UA to know that the traffic limit towards the SIP-Proxy is in thisexemplary use-case a 60% of ‘50 calls/s’, in order to guarantee thatsuch traffic is going to be attended as usual. Basically, if the SIP-UAwere able to evaluate its traffic rate towards the SIP-Proxy at themoment of the fault in the SIP-Proxy, the resulting figure should beequal to ‘50 calls/s’, or approximately the same. Nevertheless, in orderto not forcing the SIP-UA to calculate that value, and even assumingthat there might be some deviation between both figures, the SIP-Proxyindicates the reference value which the limit percentage is referred tointo the ‘Capacity-adjust’ parameter. This is the reason for having‘traffic-ref’ in the new ‘Capacity-adjust’ header.

As soon as the SIP-Proxy recovers from the abnormal situation, it mightbe interested in informing the SIP-UA about it, thus including the samenew SIP header, namely the ‘Capacity-adjust’ parameter, in any of thenext messages. The current traffic load from the SIP-UA towards theSIP-Proxy can be increased step by step, or all of a sudden, but alwaysusing the same reference value in the ‘traffic-ref’ argument. Thisreference value is the traffic load from the SIP-UA as measured by theSIP-Proxy at the time the faulty situation was detected, that is ‘50calls/s’ in the current example.

In a first exemplary embodiment following this and illustrated in FIG.-6 a-, the SIP-Proxy indicates to the SIP-UA an increase of traffic loadon a step by step performance. For example, the following three stepsare considered:

-   Capacity-adjust: 75 50 calls/s    -   Step 1:-   First traffic increase indication-   towards the SIP-UA.    -   The SIP-Proxy is recovering from the    -   fault.-   Capacity-adjust: 85 50 calls/s    -   Step 2:    -   The SIP proxy keeps on recovering from    -   the fault.-   Capacity-adjust: 100 50 calls/s    -   Step 3:    -   Last traffic increase message from the    -   SIP-Proxy towards the SIP-UA.    -   The SIP-Proxy is fully available    -   without limitation.    -   Back to normal traffic processing    -   figures.

In a second exemplary embodiment following this and illustrated in FIG.-6 b-, the SIP-Proxy indicates to the SIP-UA an increase of traffic loadon an all of a sudden performance.

-   Capacity-adjust: 100 50 calls/s    -   Just one traffic increase message from    -   the SIP-Proxy towards the SIP-UA.    -   The SIP-Proxy is fully available    -   without limitation.    -   Back to normal traffic processing    -   figures.

As may be easily appreciated, the ‘100 50 calls/s’ value does not meanthat such figure is the maximum traffic that the SIP-Proxy accepts fromthe SIP-UA from now on, but rather the end of the traffic limitationtowards the SIP-Proxy.

Further, this first procedure for traffic flow control may be refinedwith a second procedure, the so-called Capacity References Exchange inaccordance with a said second aspect of the present invention, by addingthe possibility for both SIP nodes to explicitly exchange capacityreference limits. Said capacity reference limits may be regarded as asort of traffic limits to be further used as permanent references insubsequent Capacity Adjustment Indications. These limits are typicallyestimations, which might result from some local dimensioningcalculations or from user or time profiles, and they are communicated tothe adjacent or peer node in order to establish some maximum input oroutput traffic margins that each node is able to handle under normalconditions.

Said second procedure above referred, the so-called Capacity ReferencesExchange (hereinafter referred to as CRE), is also based on handshakerelated additional features. These handshake additional features allowthe SIP nodes to negotiate, and agree on, to what extent they both areable to support such a second procedure. For instance, another object ofnegotiation between SIP nodes such as a SIP-UA and a SIP-Proxy, namely ahandshake feature, is whether a mechanism is available to establish amaximum reference limit for the traffic flow coming out from the SIP-UAtowards the SIP-Proxy. Another handshake feature within this secondprocedure is whether a mechanism is available to establish a maximumreference limit for the traffic flow coming out from the SIP-Proxytowards the SIP-UA. Indeed, if one SIP node such as a SIP-UA or aSIP-Proxy supports any of these two features, the other adjacent nodemust also support the same feature in order to effectively define limitsfor the traffic flow in the appropriate direction.

In accordance with said second aspect of the currently preferredembodiments, two new flow control related option-tags may be used ashandshake features within these secondary mechanisms in order to definewhether some capacity references may be exchanged between both nodes:

(i) the so-called ‘fcmaxrefua2proxy’, a first option-tag meaning that anagreement on this new feature indicates that a mechanism is availablefor both nodes to establish a maximum reference limit for the trafficfrom the SIP-UA towards the SIP-Proxy; and

(ii) the so-called ‘fcmaxrefproxy2ua’, a second option-tag meaning thatan agreement on this new feature indicates that a mechanism is availablefor both nodes to establish a maximum reference limit for the trafficfrom the SIP-Proxy towards the SIP-UA.

For example, when any of the nodes tells the other that it supports thenew feature ‘fcmaxrefua2proxy’, it means that it is able to start oraccept a negotiation on the maximum traffic to be handled from theSIP-UA towards the SIP-Proxy. Likewise, when any of the nodes tells theother that it supports the new feature ‘fcmaxrefproxy2ua’, it means thatit is able to start or accept a negotiation on the maximum traffic to behandled from the SIP-Proxy towards the SIP-UA.

In a similar manner as for the CAI procedure, the CRE procedure requiresboth SIP nodes handshake to what extent they support this secondprocedure, that is messages on the onward and backward directions. Andalso as for the CAI procedure, several alternative embodiments andcombinations thereof may be suggested for the SIP nodes to indicate eachother the aforementioned handshake additional features. In this respect,both the said SIP Registration mechanism and the said OPTIONS methoddescribed for the CAI procedure, conveniently adapted in accordance withthese embodiments or combinations thereof, are also appropriate for thisCapacity References Exchange (CRE) procedure. Also for this CREprocedure and for the sake of clarity, all the examples, use cases, andadditional embodiments of the present invention are hereinafterdescribed only with regard to the adapted SIP Registration mechanisms.

In FIG. -4 a- the SIP-UA can handle traffic references in bothdirections, that is, the SIP-UA supports both the ‘fcmaxrefua2proxy’ and‘fcmaxrefproxy2ua’ new features, which are thus included in the‘Supported’ header in the SIP REGISTER message. Since the SIP-Proxysupports both of them as well, the SIP-Proxy answers the successfulresult ‘200 OK’ with no ‘Unsupported’ header. From now on, both featuresare eventually enabled between both nodes, and both nodes are able tonegotiate maximum values for traffic in both directions.

In FIG. -4 b- the SIP-UA also supports both new features,‘fcmaxrefua2proxy’ and ‘fcmaxrefproxy2ua’, which are thus included inthe ‘Supported’ header in the SIP REGISTER message. However, theSIP-Proxy does not support any traffic reference negotiation for trafficfrom the SIP-Proxy to the SIP-UA and, consequently, the SIP-Proxyanswers the successful result ‘200 OK’ with an ‘Unsupported’ headerincluding the unsupported feature ‘fcmaxrefproxy2ua’. From now on justthe ‘fcmaxrefua2proxy’ is enabled and ‘fcmaxrefproxy2ua’ is finallydisabled. That is, just traffic references may be negotiated for thetraffic generated from the SIP-UA towards the SIP-Proxy.

In FIG. -4 c- the SIP-UA also supports both new features,‘fcmaxrefua2proxy’ and ‘fcmaxrefproxy2ua’, which are thus included inthe ‘Supported’ header in the SIP REGISTER message. However, theSIP-Proxy does not support any traffic reference negotiation for trafficfrom the SIP-UA to the SIP-Proxy and, consequently, the SIP-Proxyanswers the successful result ‘200 OK’ with an ‘Unsupported’ headerincluding the unsupported feature ‘fcmaxrefua2proxy’. From now on the‘fcmaxrefproxy2ua’ is enabled whereas ‘fcmaxrefua2proxy’ is eventuallydisabled. That is, just traffic references may be negotiated for thetraffic generated from the SIP-Proxy towards the SIP-UA.

In FIG. -4 d- the SIP-UA also supports both new features,‘fcmaxrefua2proxy’ and ‘fcmaxrefproxy2ua’, which are thus included inthe ‘Supported’ header in the SIP REGISTER message. However, theSIP-Proxy does not support any traffic reference negotiation for trafficfrom or to the SIP-UA and, consequently, the SIP-Proxy answers thesuccessful response ‘200 OK’ with an ‘Unsupported’ header including bothunsupported features ‘fcmaxrefua2proxy’ and ‘fcmaxrefproxy2ua’. That is,both ‘fcmaxrefproxy2ua’ and ‘fcmaxrefua2proxy’ are eventually disabled,and none of the nodes may be able to negotiate a traffic reference forthe traffic between them in any direction.

The SIP-UA in these four previous use-cases was always able to supporttraffic reference negotiation in both directions. As for the CAIprocedure, there might be situations in which the initiator of handshakeonly supports traffic reference negotiation in one direction as theexemplary four use-cases following this.

For instance, in FIG. -5 a- the SIP-UA only supports the‘fcmaxrefua2proxy’ new feature, which is thus included in the‘Supported’ header in the SIP REGISTER message. Since the SIP-Proxy alsosupports this feature, the SIP-Proxy answers the successful result ‘200OK’ with no ‘Unsupported’ header. From now on, the ‘fcmaxrefua2proxy’ isenabled whereas ‘fcmaxrefproxy2ua’ is eventually disabled. That is, justtraffic references may be negotiated for the traffic generated from theSIP-UA towards the SIP-Proxy.

In FIG. -5 b-, the SIP-UA only supports the ‘fcmaxrefua2proxy’ newfeature, which is thus included in the ‘Supported’ header in the SIPREGISTER message. However, the SIP-Proxy does not support any trafficreference negotiation for traffic from the SIP-UA and, consequently, theSIP-Proxy answers the successful result ‘200 OK’ with an ‘Unsupported’header including the unsupported feature ‘fcmaxrefua2proxy’. That is,from now on both ‘fcmaxrefproxy2ua’ and ‘fcmaxrefua2proxy’ areeventually disabled, and none of the nodes is able to negotiate trafficreferences for the traffic between them in any direction.

Also for instance, in FIG. -5 c- the SIP-UA only supports the‘fcmaxrefproxy2ua’ new feature, which is thus included in the‘Supported’, header in the SIP REGISTER message. Since the SIP-Proxyalso supports this feature, the SIP-Proxy answers the successful result‘200 OK’ with no ‘Unsupported’ header. From now on, just the‘fcmaxrefproxy2ua’ is enabled whereas ‘fcmaxrefua2proxy’ is eventuallydisabled. That is, just traffic references may be negotiated for thetraffic generated from the SIP-Proxy towards the SIP-UA.

In FIG. -5 d-, the SIP-UA only supports the ‘fcmaxrefproxy2ua’ newfeature, which is thus included in the ‘Supported’ header in the SIPREGISTER message. However, the SIP-Proxy does not support any trafficreference negotiation for traffic from the SIP-Proxy to the SIP-UA and,consequently, the SIP-Proxy answers the successful result ‘200 OK’ withan ‘Unsupported’ header including the unsupported feature‘fcmaxrefproxy2ua’. From now on, both ‘fcmaxrefproxy2ua’ and‘fcmaxrefua2proxy’ are eventually disabled, and none of the nodes isable to negotiate traffic references for the traffic between them in anydirection.

Once having completed the initial handshake for the new features‘fcmaxrefproxy2ua’ and ‘fcmaxrefua2proxy’, both SIP nodes may starttalking to each other in order to establish some limits for trafficgoing back and forth between them. In accordance with currentlypreferred embodiments, another new SIP header is proposed for exchangingthese traffic limits, namely capacity references. An exemplary formatfor said SIP header follows this:

-   Capacity-profile: “Capacity profile” “:” 1*2 maximum-load-   maximum-load: “max-ua2proxy-load” | “max-proxy2ua-load”-   max-ua2proxy-load: “u2p” “=” traffic-load    -   Maximum traffic foreseen from the    -   sender for the ‘ua-to-proxy’ traffic.-   max-proxy2ua-load: “p2u” “=” traffic-load    -   Maximum traffic foreseen from the    -   sender for the ‘proxy-to-ua’ traffic.-   traffic-load: 1*DIGIT traffic-units-   traffic-units: “mess/s” | “trans/s” | “call/s”    -   mess/s (messages per second),    -   where ‘messages’ are all SIP    -   methods (i.e. INVITE, ACK,    -   OPTIONS, BYE, CANCEL, REGISTER    -   and INFO) and all provisional    -   and final responses;    -   trans/s (transactions per        -   second), including both SIP and        -   regular transactions;    -   call/s (calls per second),    -   referred to the whole period    -   since the initial INVITE till    -   the completion of the call.-   DIGIT:    -   as described in ‘SDP: Session    -   Description Protocol’.

In this exemplary format for the new SIP header, the ‘u2p’ parameterrepresents the maximum traffic load that the sending SIP entity, forexample the SIP-UA or the SIP-Proxy, wants to process in the‘ua-to-proxy’ direction. In this respect, the ‘u2p’ parameter validityis closely associated to the ‘fcmaxrefua2proxy’ feature. If both nodeshave not successfully agreed such feature on, then the value indicatedin ‘u2p’ is useless, since at least one of the nodes is not able to useit at all as a valid reference.

Also in this exemplary format for the new SIP header, the ‘p2u’parameter represents the maximum traffic load that the sending SIPentity, for example the SIP UA or the SIP proxy, wants to process in the‘proxy-to-ua’ direction. Likewise ‘u2p’, the ‘p2u’ parameter validity isclosely associated to the ‘fcmaxrefproxy2ua’ feature. If both nodes havenot successfully agreed this feature on, then the value indicated in‘p2u’ is useless, since at least one of the nodes is not able to use itat all as a valid reference.

These parameters ‘u2p’ and ‘p2u’ define the traffic margin in therespective direction for both nodes to work in the range agreed on. Whena SIP node like for example a SIP-UA or a SIP-Proxy receives this newSIP header, this receiver node has to respond back with its own‘Capacity-profile’ to eventually agree on a traffic range valid for bothnodes. That is, the ‘Capacity-profile’ header always requires a responsefrom the other end confirming or proposing a new traffic range. Theresponse would be typically based on its own configuration data and itshould fit into the ‘Capacity-profile’ values received from the othernode. None of them can just send some ‘u2p’ and ‘p2u’ values to theopposite node within the ‘Capacity-profile’ new header and expect thatthose values suit the other node capacity requirements.

This reactive behaviour for the ‘Capacity-profile’ new header leads toseveral alternatives non-exclusive each other to carry out this CapacityReference Exchange (CRE) mechanism. As already commented above, similarrational as for the Capacity Adjustment Indication procedure can beapplied to this CRE though with less restrictions. In principle, the SIPRegistration or more precisely the REGISTER method is appropriate forsending this new header though bearing in mind that in case theSIP-Proxy needs to modify the current traffic range, it will not be ableto initiate that exchange on its own. It will need the SIP-UA to firstsend a REGISTER including a ‘Capacity-profile’ header so that the latelyagreed traffic range could be modified in the ‘200 OK’ response to suchREGISTER message. This issue may be easily fixed if the SIP-UA is forcedto always include its current ‘Capacity-profile’ values in all REGISTERmessages.

Further, a more flexible embodiment is achieved if, apart fromconsidering the REGISTER, the OPTIONS method is also used at any time toinitiate the ‘Capacity-profile’ exchange from any SIP node like forexample, the SIP-UA or the SIP-Proxy. The exchange will be completed atreception of the response to the OPTIONS method. In this case, bothnodes would be able to initiate the Capacity Reference Exchangeprocedure at any time, without limitations derived from the registrationperiod. Furthermore, there is no apparent limitation to assume that allthe SIP methods like INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER andINFO may be carrying such new SIP header to successfully accomplish theCapacity Reference Exchange procedure.

Generally speaking and as shown in FIG. -7 a-, a SIP-UA registers at aSIP-Proxy, and decides to use such registration process to handshakeboth ‘fcmaxrefua2proxy’ and ‘fcmaxrefproxy2ua’ new features. Since theSIP-UA supports both features, it is able to start negotiating both‘u2p’ and ‘p2u’ parameters in the ‘Capacity-profile’ header to establishtraffic margins for traffic to or from the SIP-Proxy. The SIP-Proxyconfirms the support for ‘fcmaxrefua2proxy’. In fact, the SIP-Proxysends back a final agreement on ‘u2p’ by reducing to ‘10 call/s’ the ‘15call/s’ proposed by the SIP-UA. Besides, the SIP-Proxy indicates that‘fcmaxrefproxy2ua’ is not supported and, consequently, no agreement on‘p2u’ may be accepted. Any further ‘Capacity-profile’ indication willjust include the ‘u2p’ parameter, and no ‘p2u’ at all. If any node wereinterested in using ‘p2u’ it should negotiate again the support for‘fcmaxrefproxy2ua’ by carrying out a new handshake.

Once both primary and secondary mechanisms have been respectivelyintroduced for both Capacity Adjustment Indication (CAI) procedure andCapacity Reference Exchange (CRE) procedure, some of the aforementionedembodiments of isolated handshakes may be merged into new embodimentswherein handshake features from both procedures are simultaneouslynegotiated. For example in FIG. -7 b- all handshake features areproposed by the SIP-UA in one step. As a result of the handshake theflow control will only be carried out from the SIP-UA towards theSIP-Proxy, the SIP-Proxy will be able to send ‘Capacity-adjust’indications to the SIP-UA to modify the traffic flow towards saidSIP-Proxy, and the SIP-UA will accept those indications from saidSIP-Proxy. Moreover, both nodes agree on a maximum rate for the trafficfrom the SIP-UA towards the SIP-Proxy, which is set to ‘u2p=20transactions per second’, the lower value as proposed from theSIP-Proxy. That value may be used as a reference in further‘Capacity-adjust’ indications sent from the SIP-Proxy to the SIP-UA interms of ‘traffic-ref=20 tran/s’ accordingly with a preferred embodimentabove. On the other hand, the SIP-UA will not be able to send‘Capacity-adjust’ indications to the SIP-Proxy since said SIP-Proxy doesnot support ‘fcproxy2ua’. Given that the SIP-Proxy does not support‘fcmaxrefproxy2ua’, such SIP-Proxy is not interested in defining amaximum value for the traffic from said SIP-Proxy towards the SIP-UAand, consequently, the ‘p2u’ parameter in ‘Capacity-profile’ is not usedat all.

As supporting both CAI and CRE procedures in a SIP node like a SIP-UA ora SIP-Proxy, the flow control mechanisms rely on the proposed newheaders ‘Capacity-adjust’ and ‘Capacity-profile’. Said new headers maybe differently used depending on whether there is a short-term or along-term capacity variation to act upon.

For instance, if there is a temporary situation in the affected nodeleading to a capacity decrease that will probably be restored in short,the ‘Capacity-adjust’ header would be more suitably selected, thus beinga percentage referred to the last received ‘Capacity-profile’. When theproblem is over, a new ‘Capacity-adjust’ may be sent to increase thecapacity again by referring to the same reference value in the lastreceived ‘Capacity-profile’. However, if there seems to be a new,long-term capacity context in the affected node, the ‘Capacity-profile’header would be more appropriate. This header would clearly state thatthe capacity reference to be used onwards in the opposite node shouldchange.

An example on how these two new headers may be used to implement flowcontrol mechanisms between a SIP-UA and a SIP-Proxy is shown in FIG.-8-. In this example, the registration period has been used to negotiateall handshake features as well as to exchange the ‘capacity profiles’.In particular, this initial handshake is the same as the one presentedin FIG. -7 b- already commented. After this initial handshake, theSIP-Proxy requests the SIP-UA to reduce its traffic towards theSIP-Proxy down to a 50% of the ‘u2p’ reference previously agreed, whichis ‘20 call/s’. Later, the SIP-Proxy gets over the limiting situationand informs the SIP-UA that the traffic can be increased again. To thisend, an exemplary two-step approach has been used. In the first step,the SIP-Proxy tells the SIP-UA to increase the traffic up to 75% of thecurrent ‘u2p’ reference. In the second step, the SIP-UA is told that theSIP-Proxy is back to its normal behaviour, namely 100% of the current‘u2p’ reference. At this point, it has to be noticed that any SIPmessage might have been used to carry the ‘Capacity-adjust’ header inaccordance with a preferred embodiment above. Further, for instanceafter a couple of registration periods, both nodes agree on a newtraffic reference for the traffic from the SIP-UA towards the SIP-Proxy,which is eventually agreed on a ‘u2p=40 call/s’. Then, once again, theSIP-Proxy requests a new decrease of traffic rate from the SIP-UA downto 75% of the current ‘u2p’ reference. Eventually, the SIP-Proxyrecovers from the limiting situation and uses a single-step approach toinform the SIP-UA about it by saying that 100% of ‘40 call/s’ isavailable.

The previous example is an appropriate instance of a common initialhandshake wherein all the features are negotiated in a single step.However, there is no apparent restriction to handshake firstly featuresrelated to CAI procedure and secondly features related to CREprocedures, or vice versa. Nevertheless, the CAI procedure and relatedfeatures represent the essential mechanisms to implement a real flowcontrol, thus, handshaking only features related to CRE procedure willnot really implement flow control mechanisms until having negotiated andagreed on CAI procedure related features.

For instance, features related to the CAI procedure are negotiated firstin a situation like the one presented in FIG. -2 b-. As a result of theinitial handshake shown in FIG. -2 b-, the SIP proxy is able to send‘Capacity-adjust’ indications to the SIP-UA in order to modify thetraffic flow towards the SIP-Proxy and, since ‘fcua2proxy’ is supported,the SIP-UA accepts the corresponding indications from the SIP-Proxy.However, the SIP-UA is not able to send ‘Capacity-adjust’ indications tothe SIP-Proxy since said SIP-Proxy does not support ‘fcproxy2ua’. On theother hand, no explicit capacity references are exchanged between bothnodes because no feature related to CRE procedure has been negotiatedyet. Thus, the ‘traffic-ref’ argument in any further ‘Capacity-adjust’indication from the SIP-Proxy to the SIP-UA will not include anyexplicit capacity reference previously exchanged between both nodes.Instead, said ‘traffic-ref’ argument may include the current‘ua-to-proxy’ traffic figures measured by the SIP-Proxy as deciding avariation of the traffic rate from the SIP-UA. Next, the other featuresrelated to CRE, ‘fcmaxrefua2proxy’ and ‘fcmaxrefproxy2ua’ may beseparately negotiated as presented in FIG. -7 c-. Since‘fcmaxrefua2proxy’ is supported, FIG. -7 c- shows that both nodes agreeon a maximum rate for the traffic from the SIP-UA towards the SIP-Proxy,which is finally set to ‘u2p=20 transactions per second’. This figurewill be used as a reference in further ‘Capacity-adjust’ indicationssent from the SIP-Proxy to the SIP-UA, that is ‘traffic-ref=20 tran/s’.Besides, given that the SIP-Proxy does not support ‘fcmaxrefproxy2ua’,said SIP-Proxy is not interested in defining a maximum rate for thetraffic from the SIP-Proxy towards the SIP-UA. After this secondhandshake, the behaviour of both nodes will be the same as if all fourfeatures had been negotiated at the same time, as above explained withreference to -7 b-.

Another instance of alternating the primary and secondary mechanisms isthe negotiation of features related to the CRE procedure first, and thenthe negotiation of features related to the CAI procedure. For example,as a result of the initial handshake shown in FIG. -7 c-, both nodesagree on a maximum rate for the traffic from the SIP-UA towards theSIP-proxy which is eventually set to ‘u2p=20 transactions per second’,the lower value as proposed from the SIP-Proxy. There will be no further‘Capacity-adjust’ indications, until having negotiated the CAI relatedfeatures, ‘fcua2proxy’ and ‘fcproxy2ua’. This means that the SIP-UA canonly avoid going over this capacity reference value in order to precluderequest rejections from the SIP-Proxy. In other words, no complete flowcontrol mechanism exists yet. On the other hand, and given that theSIP-Proxy does not support ‘fcmaxrefproxy2ua’, the SIP-Proxy is notinterested in defining a maximum value for the traffic from saidSIP-Proxy towards the SIP-UA. Next, the other features related to CAIprocedure, ‘fcua2proxy’ and ‘fcproxy2ua’ may be separately negotiated aspresented in FIG. -2 b-. Given that ‘fcua2proxy’ is supported, theSIP-Proxy is able to send ‘Capacity-adjust’ indications to the SIP-UA inorder to modify the traffic rate towards the SIP-Proxy, and the SIP-UAaccepts those indications from the SIP-Proxy. In this respect, the‘traffic-ref’ argument in any further ‘Capacity-adjust’ indication sentfrom the SIP-Proxy to the SIP-UA is set to the ‘u2p’ argument exchangedin the previous initial handshake for CRE related features, namely‘traffic-ref=20 tran/s’. On the other hand, the SIP-UA will not be ableto send ‘Capacity-adjust’ indications to the SIP-Proxy since saidSIP-Proxy does not support ‘fcproxy2ua’. After this second handshake,and as for the previous instance of ordering procedures, the behaviourof both nodes will be the same as if all four features had beennegotiated at the same time, as above explained with reference to FIG.-7 b-.

Further to the activation of the aforementioned CAI and CRE procedures,primary mechanisms for providing traffic flow control and secondarymechanisms for providing additional fine adjustment respectively, theremay be needs for a partial or complete deactivation of said CAI and CREprocedures. As already commented for previous embodiments, all theseflow control mechanisms are not established on individual call basis butrather on nodal capacity basis. Consequently, there is no apparent needto negotiate the corresponding features at every call, transaction, ormessage request. That is why the negotiation of traffic flow controlrelated features has been preferably suggested during the registrationperiods, though other SIP methods and messages may be applied as well.However, the REGISTER requests are additive in the sense that featuresprovided by a certain registration do not completely replace all earlierones. On the other hand, another possibility already suggested for theinitial negotiation and further re-negotiations is the OPTIONS method.In this respect, any OPTIONS request represents a flow controlnegotiation to establish a flow control context just valid until a nextOPTIONS request is issued. Then, if every OPTIONS method were just usedto query about new features, and assuming that those previouslynegotiated are still enabled, there would be no way to disable apreviously negotiated feature. These are some reasons to justify theneeds for a specific mechanism to deactivate CAI and CRE procedures andrelated features.

In accordance with a currently preferred embodiment another new SIPheader is generally proposed for the deactivation of any feature relatedto said CAI and CRE procedures, and for which an exemplary formatfollows this: Deactivate = “Deactivate” “:” 1#option-tag

Any SIP node, like the SIP-UA or the SIP-Proxy for instance, wanting todeactivate any flow control related feature may just include this‘Deactivate’ header in any SIP message to the opposite node indicatingsaid particular flow control related feature wanted to be deactivated.Said ‘Deactivate’ header may be used in a similar manner as the‘Supported’ header, and may also be included in responses to any messagerequest. In particular, said ‘Deactivate’ header might be included inany request from a SIP-UA, from a SIP-Proxy, and from a SIP-Server.Moreover, there is no apparent need to expect any response orconfirmation from the receiver node prior to consider the indicatedfeature as deactivated.

In a first example illustrated in FIG. -9 a-, all the flow control andfine adjustment related features might be deactivated in just one stepfrom a SIP node, like a SIP-Proxy, by including all of them in a‘Deactivate’ header in any SIP message to be submitted to another SIPnode like a SIP-UA. In a second example illustrated in FIG. -9 b-, justfeatures related to flow control and fine adjustment in a singledirection. This FIG. -9 b- shows how a SIP-UA deactivates the flowcontrol and fine adjustment related features in the direction from theSIP-Proxy to the SIP-UA by including them in a ‘Deactivate’ header inany SIP message to be submitted from said SIP-UA to said SIP-Proxy. Inthis situation, the corresponding features in the other direction fromSIP-UA to SIP-Proxy remain unchanged. A third example in FIG. -9 c-shows how the flow control and fine adjustment related features might bedeactivated from any SIP node of a couple of SIP nodes implementingthese primary and secondary traffic flow control mechanisms in anyorder. As shown in FIG. -9 c-, a SIP-Proxy deactivates the flow controlrelated feature in the direction from the SIP-Proxy to the SIP-UA byincluding it in a ‘Deactivate’ header in any SIP message to be submittedfrom said SIP-Proxy to said SIP-UA. Further, the SIP-UA deactivates theflow control and fine adjustment related features in the direction fromthe SIP-UA to the SIP-Proxy by including them in a ‘Deactivate’ headerin any SIP message to be submitted from said SIP-UA to said SIP-Proxy.Eventually, the former SIP-Proxy deactivates the remaining fineadjustment related feature in the direction from the SIP-UA to theSIP-Proxy by including it in a ‘Deactivate’ header in another SIPmessage to be submitted from said SIP-Proxy to said SIP-UA. Eventually,a fourth example in FIG. -9 d- shows how each SIP node deactivates theflow control and fine adjustment related features in its own direction.That is, the SIP-UA deactivates flow control and fine adjustmentfeatures from the SIP-Proxy to said SIP-UA whereas the SIP-Proxydeactivates the same features from the SIP-UA to said SIP-Proxy.

As anyone skilled in the art may appreciate this approach, carried outby combination of ‘Supported’ and ‘Deactivate’ headers, might be usednot only for these flow control purposes but also for any otherfeature-controlled service or function wherein a SIP node request theadjacent node the invocation of the indicated service or function bymaking use of a ‘Supported’ header whereas the requester or the adjacentnode itself may disable such service or function by making use of the‘Deactivate’ header.

After having fully explained the traffic flow control related mechanismsin a basic scenario comprising a couple of SIP nodes like a SIP-UA and aSIP-Proxy, other more general scenarios can be pointed out, said generalscenarios comprising a plurality of nodes acting as SIP-UA and aplurality of nodes acting as SIP-Proxy. For instance, several SIP-UA areconnected to the same SIP-Proxy, what is generally known nowadays in SIPSpecifications as an Outbound Proxy, or a single SIP-UA is connected tomore than one SIP-Proxy, what results in different routes to or from theSIP network. Moreover, the most general scenario wherein more than oneSIP-UA are connected to more than one SIP-Proxy is shown in FIG. -10-and reflects the actual flexibility as registering at least one of aplurality of SIP-UA into a SIP network to provide access for a bunch ofusers to those services available in said SIP network.

The case in FIG. -10- where a single SIP-Proxy (SIP Proxy-1) has gotregistrations from more than one SIP-UA (SIP UA-1, SIP UA-2, SIP UA-3,SIP UA-N) deserves some extra considerations apart from what has beenhereinbefore described. Said considerations may add particular detailsto every specific implementation, but do not present relevant impacts tothe CAI and CRE procedures in accordance with the invention. In thisrespect, a SIP-Proxy must be able to handle the aforementioned CAI andCRE procedures for the amount of SIP-UA having registered. For thispurpose, SIP-Proxy is still able to measure its own total trafficcapabilities, accommodating and distributing such figures amongst theamount of SIP-UA. Moreover, said SIP-Proxy may decide whether thetraffic to or from certain SIP-UA needs to be under some more rigorouscontrol. Further, said SIP-Proxy may distribute its total traffichandling capacity between some or all the existing SIP-UA connections byusing pre-determined or dynamically configured criteria. For example, afirst generic criterion may be the support of SIP-UA priority lists on aper SIP-Proxy basis. Besides, other individual criteria might be theaverage traffic per SIP-UA, pre-defined minimum or maximum initialcapacity assigned per SIP-UA, no initial capacity assigned andnegotiation required for some particular SIP-UA for example, and manyothers as well as combinations thereof. Similar consideration as thepreceding ones may be made in respect of the whole scenario presented inFIG. -10- wherein a plurality of SIP-Proxies have got more than oneSIP-UA registered with insignificant complexity that anyone of ordinaryskill in the art may solve by extending this rational.

These embodiments above and varieties thereof are presented in anillustrative and non-restrictive manner in accordance with the presentinvention to accomplish the aforementioned Capacity AdjustmentIndication (CAI) procedure, core part of traffic flow controlmechanisms, and the aforementioned Capacity References Exchange (CRE)procedure, additional fine adjustment of traffic flow controlmechanisms. It is expected that these embodiments may still be amendedby anyone of ordinary skill in the art without substantially modifyingthe scope of the invention.

1. A method for controlling traffic flow in a telecommunication networkincluding a plurality of network nodes, each network node having atemporary different capacity limitation for handling signallingmultimedia sessions over data networks, the method comprising the stepsof: (a) negotiating between two network nodes whether a mechanism existin both nodes for controlling the traffic flow between said nodes inboth directions, from a traffic sender node to a traffic receiver node;(b) determining the capacity limitation of at least one traffic receivernode; and (c) accommodating the traffic load between the traffic sendernode and the traffic receiver node to the capacity limitation of thetraffic receiver node; wherein the mechanism is a capacity adjustmentindication CAI mechanism and the negotiation in the above step a)includes the steps of: (a1) indicating from a requester to a requestednode of said network nodes at least one traffic flow direction for whichthe capacity adjustment indication mechanism is supported in therequester node; (a2) answering from the requested to the requester nodewhether the CAI mechanism for said traffic flow direction is alsosupported in the requested node; and (a3) marking at the requester andrequested nodes any traffic flow direction for which a CAI mechanism issupported in both nodes.
 2. A method according to claim 1, wherein thecapacity limitation in the above step b) is determined by a capacityadjustment indication received at the traffic sender node from thetraffic receiver node when corresponding traffic flow direction issupported in both nodes.
 3. A method according to claim 2, wherein saidcapacity adjustment indication sent from the traffic receiver node tothe traffic sender node includes: information about the maximum incomingtraffic load that said traffic receiver node is able to deal with fromsaid traffic sender node; and the units (calls/s) in which traffic ismeasured.
 4. A method according to claim 1, further comprising the stepsof: (d) negotiating between said two network nodes whether a capacityreference exchange (CRE) mechanism exist in both nodes for establishingmaximum reference limits for the traffic flow between them in bothdirections, said negotiation being initiated at any one of said nodes;and (e) using a CRE mechanism for establishing a maximum reference limitfor the traffic flow between said nodes in at least one direction of thetraffic flow, including the following steps: (e1) determining at eachnode the maximum traffic load that said node supports for sending to, orreceiving from, the other node in said direction of the traffic flow;and (e2) both nodes exchanging their respective capacity references(Capacity-profile) in said direction of the traffic flow, saidreferences including when applicable the maximum traffic load in theincoming or outgoing direction, and the units in which traffic ismeasured.
 5. A method according to claim 4, wherein the step d) ofnegotiating includes the steps of: (d1) indicating from a requester to arequested node of said network nodes at least one traffic flow directionfor which a CRE mechanism is supported in the requester node; (d2)answering from the requested to the requester node whether said CREmechanism for said traffic flow direction is also supported in therequested node; and (d3) marking at the requester and requested nodesany traffic flow direction for which a CRE mechanism is supported inboth nodes.
 6. A method according to claim 4, wherein the step e2) ofexchanging respective capacity references comprises the steps of: (e2-a)proposing from a requester to a requested node the capacity reference(Capacity-profile) determined at said requester node for said directionof the traffic flow, said capacity reference including when applicablethe maximum traffic load in the incoming or outgoing direction, and theunits in which traffic is measured; (e2-b) checking at the requestednode whether said capacity reference received from the requester node isbeing supported or a lower capacity reference value is being granted tosaid requester node; (e2-c) granting from the requested to the requesternode a capacity reference supported by both nodes; (e2-d) storing atboth requester and requested nodes the capacity reference supported byboth nodes.
 7. A method according to claim 1, wherein the multimediasessions are signalled by a protocol operating in accordance with aSession Initiation Protocol.
 8. A method according to claim 7, whereinthe requester node indicates during negotiation the at least one trafficflow direction for which a CAI mechanism is supported by making use of a‘Supported’ header including indications of specific supported trafficflow directions.
 9. A method according to claim 7, wherein the requestednode answers during negotiation of the CAI mechanism by returning asuccessful acknowledge, said acknowledge either with an ‘Unsupported’header including unsupported traffic flow directions from thosereceived, or with no header where the received traffic flow directionsare supported.
 10. A method according to claim 7, wherein: the requesternode indicates during negotiation the at least one traffic flowdirection for which a CRE mechanism is supported by making use of a‘Supported’ header including indications of specific supported trafficflow directions; and the requested node answers during negotiation ofthe CRE mechanism by returning a successful acknowledge, saidacknowledge either with an ‘Unsupported’ header including unsupportedtraffic flow directions from those received, or with no header where thereceived traffic flow directions are supported.
 11. A method accordingto claim 7, wherein the capacity adjustment indications are sent bymaking use of a so-called ‘Capacity-adjust’ header comprising parametersfor incoming traffic load information in respect of a given maximumreference limit, and the units in which said traffic load is measured.12. A method according to claim 7, wherein the capacity references aresent by making use of a so-called ‘Capacity-profile’ header comprisingparameters for the maximum traffic load in the incoming direction, andfor the maximum traffic load in the outgoing direction acceptable to andfrom a certain network node.
 13. A method according to claim 1, whereinat least one network node is a node selected from a group of nodescomprising: a node acting as a Session Initiation Protocol User Agent(SIP UA); a node acting as a Session Initiation Protocol Proxy (SIPProxy); a node acting as a Session Initiation Protocol Server; and aMedia Gateway controller (MGC) acting as a Session Initiation ProtocolUser Agent (SIP UA).
 14. A telecommunications system comprising a firstmedia domain (SIP Domain) wherein multimedia sessions are signalled by aprotocol operating according to a Session Initiation Protocol; a secondmedia domain (Telephony Domain) wherein multimedia sessions aresignalled by a protocol operating according to a second standard; aMedia Gateway (MGW) in charge of receiving and sending media betweensaid first and second media domains; a Media Gateway Controller forreceiving and sending signalling related to multimedia sessions from andto network nodes in said first and second media domains, and having atleast two connected nodes carrying out a negotiation to agree on whethera mechanism exists in both nodes for controlling the traffic flowbetween them in at least one of both directions, wherein the mechanismis a capacity adjustment indication CAI mechanism and said negotiationbetween connected nodes being initiated at any one of said nodes andcomprising: (a) a requester node indicating to each requested node atleast one traffic flow direction for which the capacity adjustmentindication mechanism is supported in the requester node; (b) therequested node answering to the requester node whether said CAImechanism for said traffic flow direction is also supported in therequested node; and (c) both requester and requested nodes marking on aper requester and requested basis any traffic flow direction for which aCAI mechanism is supported in both nodes.
 15. A telecommunicationssystem according to claim 14, wherein the requester node has agreedduring negotiation with the requested node on both nodes supporting aCAI mechanism for flow control from a traffic sender node to a trafficreceiver node, said traffic receiver node having: (a) means fordetermining its capacity limitation available for traffic incoming fromsaid traffic sender node; and (b) means for sending a capacityadjustment indication to said traffic sender node for accommodating thetraffic flow toward the traffic receiver node according to the capacitylimitations in the traffic receiver node.
 16. A telecommunicationssystem according to claim 14, wherein the two connected nodes carry outa second negotiation to agree on whether capacity reference exchange(CRE) mechanisms exist in both nodes for establishing maximum referencelimits for the traffic flow in at least one of both directions, saidnegotiation being initiated at any one of said nodes and furthercomprising: (a) a requester node indicating to a requested node at leastone traffic flow direction for which a CRE mechanism is supported in therequester node; (b) the requested node answering to the requester nodewhether said CRE mechanism for said traffic flow direction is alsosupported in the requested node; and (c) both requester and requestednodes marking on a per requester and requested basis any traffic flowdirection for which a CRE mechanism is supported in both nodes.
 17. Atelecommunications system according to claim 16, wherein the requesternode has agreed during said second negotiation with the requested nodeon both nodes supporting a CRE mechanism for establishment of a maximumreference limit for the traffic flow in at least one traffic flowdirection between said nodes, (a) each node having means for determiningthe maximum traffic load that said node supports for sending to, orreceiving from, the other node in said traffic flow direction, and (b)both nodes having means for exchanging their respective capacityreferences in said traffic flow direction, including the maximum trafficload in the incoming or outgoing direction, and the units in whichtraffic is measured.
 18. A telecommunications system according to claim17, wherein the means for exchanging respective capacity references forthe traffic flow in at least one traffic flow direction, comprises: (b1)means for proposing from the requester node to the requested node thecapacity reference determined at said requester node for said trafficflow direction, said capacity reference including when applicable themaximum traffic load in the incoming or outgoing direction, and theunits in which traffic is measured; (b2) the requested node checkingwhether said capacity reference received from the requester node isbeing supported or a lower capacity reference is being granted to saidrequester node; (b3) the requested node granting to the requester node acapacity reference supported by both nodes; and (b4) both requester andrequested nodes storing the capacity reference supported by both nodes.19. A telecommunications system according to claim 14, wherein at leastone node in said telecommunications system is a node selected from agroup of nodes comprising: a node acting as a Session InitiationProtocol User Agent (SIP UA); a node acting as a Session InitiationProtocol Proxy (SIP Proxy); a node acting as a Session InitiationProtocol Server; and a Media Gateway Controller (MGC) acting as aSession Initiation Protocol User Agent (SIP UA).
 20. A Media GatewayController for exchanging signalling traffic related to multimediasessions with a network node of a media domain wherein the multimediasessions are signalled by a protocol operating according to a SessionInitiation Protocol, the Media Gateway Controller comprising: (a) firstprotocol means for negotiating with the network node whether a mechanismexist for controlling the traffic flow between them in both directionsfrom a traffic sender node to a traffic receiver node; (b) firstprocessing means for determining capacity limitations of at least onetraffic receiver node; and (c) traffic limitation means foraccommodating the traffic load between the traffic sender node and thetraffic receiver node to the capacity limitation of the traffic receivernode; wherein said first protocol means a) further comprises: (a1) meansfor indicating to the network node at least one traffic flow directionfor which a capacity adjustment indication (CAI) mechanism is supportedin the Media Gateway Controller; (a2) means for receiving an indicationfrom the network node of at least one traffic flow direction for which acapacity adjustment indication (CAI) mechanism is supported in saidnetwork node; and (a3) means for marking any traffic flow direction forwhich the CAI mechanism is supported in both Media Gateway Controllerand network node.
 21. A Media Gateway Controller according to claim 20,wherein the first processing means b) comprises: (b1) means for sendinga capacity adjustment indication to the network node when both MediaGateway Controller and network node support the CAI mechanism in thetraffic flow direction towards the Media Gateway Controller; and (b2)means for receiving a capacity adjustment indication from the networknode when both Media Gateway Controller and network node support the CAImechanism in the traffic flow direction towards the network node.
 22. AMedia Gateway Controller according to claim 20, further comprising: (d)second protocol means for negotiating with the network node whether acapacity reference exchange (CRE) mechanism exists for establishingmaximum reference limits for the traffic flow between them in bothdirections from a traffic sender node to a traffic receiver node; and(e) second processing means for determining capacity references thateach node supports for sending to, or receiving from, the other node inat least one direction of the traffic flow.
 23. A Media GatewayController according to claim 22, wherein the second protocol means d)includes: (d1) means for indicating to the network node at least onetraffic flow direction for which a CRE mechanism is supported in theMedia Gateway Controller; (d2) means for receiving an indication fromthe network node of at least one traffic flow direction for which a CREmechanism is supported in said network node; and (d3) means for markingany traffic flow direction for which the CRE mechanism is supported inboth Media Gateway Controller and network node.
 24. A Media GatewayController according to claim 22, wherein the second processing means e)includes: (e1) means for sending a capacity reference to the networknode when both Media Gateway Controller and network node support the CREmechanism in the traffic flow direction towards the Media GatewayController; and (e2) means for receiving a capacity reference from thenetwork node when both Media Gateway Controller and network node supportthe CRE mechanism in the traffic flow direction towards the networknode.
 25. A proxy node of a media domain for exchanging signallingtraffic related to multimedia sessions with a user agent node, themultimedia sessions being signalled by a protocol operating according toa Session Initiation Protocol, the proxy node comprising: (a) firstprotocol means for negotiating with the user agent node whether amechanism exist for controlling the traffic flow between them in bothdirections from a traffic sender node to a traffic receiver node; (b)first processing means for determining capacity limitations of at leastone traffic receiver node; and (c) traffic limitation means foraccommodating the traffic load between the traffic sender node and thetraffic receiver node to the capacity limitation of the traffic receivernode; wherein said first protocol means a) further comprises: (a1) meansfor indicating to the user agent node at least one traffic flowdirection for which a capacity adjustment indication (CAI) mechanism issupported in the proxy node; (a2) means for receiving an indication fromthe user agent node of at least one traffic flow direction for which acapacity adjustment indication (CAI) mechanism is supported in said useragent node; and (a3) means for marking any traffic flow direction forwhich the CAI mechanism is supported in both user agent node and proxynode.
 26. A proxy node according to claim 25, wherein the firstprocessing means b) comprises: (b1) means for sending a capacityadjustment indication to the user agent node (SIP UA) when both useragent node and proxy node support the CAI mechanism in the traffic flowdirection towards the proxy node; and (b2) means for receiving acapacity adjustment indication from the user agent node when both useragent node and proxy node support the CAI mechanism in the traffic flowdirection towards the user agent node.
 27. A proxy node according toclaim 25, further comprising: (d) second protocol means for negotiatingwith the user agent node whether a capacity reference exchange (CRE)mechanism exists for establishing maximum reference limits for thetraffic flow between them in both directions from a traffic sender nodeto a traffic receiver node; and (e) second processing means fordetermining capacity references that each node supports for sending to,or receiving from, the other node in at least one direction of thetraffic flow.
 28. A proxy node according to claim 27, wherein the secondprotocol means d) includes: (d1) means for indicating to the user agentnode at least one traffic flow direction for which a CRE mechanism issupported in the proxy node; (d2) means for receiving an indication fromthe user agent node of at least one traffic flow direction for which aCRE mechanism is supported in said user agent node; and (d3) means formarking any traffic flow direction for which the CRE mechanism issupported in both user agent node and proxy node.
 29. A proxy nodeaccording to claim 27, wherein the second processing means e) includes:(e1) means for sending a capacity reference to the user agent node whenboth user agent node and proxy node support the CRE mechanism in thetraffic flow direction towards the proxy node; and (e2) means forreceiving a capacity reference from the user agent node when both useragent node and proxy node support the CRE mechanism in the traffic flowdirection towards the user agent node.